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STATEMENT OF THE CASE 

The Appellants appeal the Examiner's rejection of claims 1-22 under 
authority of 35 U.S.C. § 134(a). The Board of Patent Appeals and 
Interferences (BPAI) has jurisdiction under 35 U.S.C. § 6(b). 

We affirm. 

Appellants' Invention 
The Appellants invented a database management system and method 
for performing refresh operations on a materialized view utilizing a base 
table, the materialized view, and a refresh log. (Abstract; Spec. 8, f [0022]; 
9,1[0024].) 2 

Claims 

Independent claims 1 and 6 further illustrate the invention. They read 
as follows: 

1. A system for performing refresh operations, the 
system comprising: 

a base table having a first plurality of data entries; 

a first materialized view that comprises a second plurality 
of data entries, the second plurality of data entries being 
associated with the first plurality of data entries in the base 
table; 

a refresh log that contains a plurality of changes in the 
base table; and 



2 We refer to Appellants' Specification ("Spec") and Appeal Brief ("Br.") 
filed August 27, 2007. We also refer to the Examiner's Answer ("Ans.") 
mailed December 31, 2007. 
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a module adapted to perform a refresh operation on the 
first materialized view using the second plurality of data entries, 
the module configured to; 

access the refresh log and the first materialized 

view; 

calculate a plurality of delta values from the 
plurality of changes in the refresh log and the second plurality 
of data entries in the first materialized view; 

apply the plurality of delta values to the second 
plurality of data entries in the first materialized view; and 

provide the plurality of delta values to a delta 
adaptation module for updating a second materialized view. 

6. A system for performing a pipelined refresh, the 
system comprising: 

a first materialized view derived at least partially from a 
base table; 

a refresh log having a plurality of entries, each of the 
plurality of entries corresponding to a change in the base table, 

a second materialized view derived at least partially from 
the first materialized view; 

a refresh module that comprises; 

a first delta calculation module that calculates a plurality 
of delta values that represents the changes to the first 
materialized view; 

a first delta processing module that applies the plurality 
of delta values to the first materialized view; 

a delta adaptation module that receives the plurality of 
delta values from the first delta calculation module and 
calculates a plurality of changes to the second materialized 
view; 

a second delta calculation module that obtains the 
plurality of changes to the second materialized view from the 
delta adaptation module; and 
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a second delta processing module that applies the 
plurality of changes to the second materialized view from the 
second delta calculation module to the second materialized 
view. 

References 

The Examiner relies on the following references as evidence of 
unpatentability: 

Sun US 5,963,959 Oct. 5, 1999 

Gupta US 7,111,020 Bl Sept. 19, 2006 

Rejections 

The Examiner rejects claims 1, 3, 5, 11-17, and 20 under 35 
U.S.C. § 102(b) as anticipated by Sun. 3 

The Examiner rejects claims 2, 4, 6-10, 18, 19, 21, and 22 under 35 
U.S.C. § 103(a) as being unpatentable over the combination of Sun and 
Gupta. 



3 We note that the Examiner rejects dependent claim 2 in view of the Sun 
and Gupta references and dependent claim 3 in view of only the Sun 
reference. Claim 3 depends on claim 2. Thus, it appears that the Examiner 
erred in grouping the rejected claims. Appellants do not object to the 
rejection of claim 3 as improper, and we interpret the Examiner's rejection 
as rejecting claim 3 under 35 U.S.C. § 103(a) over each of the references 
cited with respect to claim 2. Accordingly, we view the Examiner's mistake 
as harmless error. 
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Claim Groupings 
Based on Appellants' arguments in the Brief, we find the following 
claim groupings. Appellants argue the limitations of independent claim 1 
and mention independent claims 11, 12, and 20 with respect to the § 102(b) 
rejection, but provide no additional arguments with respect to independent 
claims 11, 12, and 20 or dependent claims 3 (see note 3 supra), 5, and 13-17. 
(Br. 8-17.) Appellants also argue the limitations of independent claim 6 
with respect to the § 103(a) rejection, but provide no additional arguments 
with respect to dependent claims 2, 3 (see note 3 supra), 4, 7-10, 18, 19, 21, 
and 22. (Br. 17-22.) Accordingly, we find Appellants do not separately 
argue claims 2-5 and 7-22. Therefore, Appellants waive separate argument 
of independent claims 11, 12, and 20. Dependent claims 2-5, 13-19, 21, and 
22 stand or fall with independent claim 1. Dependent claims 7-10 stand or 
fall with independent claim 6. We address only claims 1 and 6, infra. We 
address only those arguments that Appellants present in the Brief. 
Arguments that Appellants could have made but chose not to make in the 
Brief are waived. See 37 C.F.R. § 41.37(c)(l)(vii) ("Notwithstanding any 
other provision of this paragraph, the failure of appellant to separately argue 
claims which appellant has grouped together shall constitute a waiver of any 
argument that the Board must consider the patentability of any grouped 
claim separately."). 

ISSUES 

Based on Appellants' contentions, as well as the findings and 
conclusions of the Examiner, the pivotal issues before us for review are as 
follows. 



5 



Appeal 2009-004053 
Application 10/813,843 



1 . Do Appellants establish that the Examiner erred in finding the 
Sun reference discloses: (1) a module configured to access a refresh log and 
a first materialized view; (2) a module adapted refresh a first materialized 
view using a second plurality of data entries; (3) a module calculating a 
plurality of delta values from a plurality of changes in a refresh log and a 
second plurality of data values in a first materialized view; and (4) a module 
configured to apply a plurality of delta values to a second plurality of data 
entries in a first materialized view? 

2. Do Appellants establish that the Examiner erred in finding the 
Sun and Gupta references collectively teach or would have suggested: (1) a 
first delta processing module that applies a plurality of delta values to a first 
materialized view; and (2) a first delta calculation module, a second delta 
calculation module, and a second processing delta module? 

FINDINGS OF FACT (FF) 
Sun Reference 

1 . Sun describes a system and method for performing a fast 
refresh on a snapshot view of a database. The database includes a master 
table with data values that may be displayed in a master view as well as a 
snapshot view. Sun detects modifications to the master table and records 
primary key values in a master log - the primary key values represent 
primary keys stored in each row of the master table. During the refresh 
Sun's system reconciles the snapshot and the master table/master view 
utilizing the primary key values associated with the master table and stored 
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in the master log. (Abstract; col. 1, 11. 9-15; col. 4, 1. 28 to col. 6, 1. 66; Figs. 
2(a)-2(e), 3, 4(a)-4(e).) 

2. Sun's snapshot is a materialized view of a body of data 
constructed from the master table. (Col. 1, 11. 9-15, col. 4, 1. 66 to col. 5, 1. 
2.) 

3. Sun describes the "operation of a fast refresh mechanism" (col. 
5, 11. 10-11), i.e., computer programming operable to perform refresh 
functions. For example, Sun describes utilizing SQL statements to update 
(refresh) the snapshot with revised data values from the master table/master 
view. (Col. 4, 1. 28 to col. 6, 1. 66; Figs. 2(a)-2(e), 3, 4(a)-4(e).) 

Gupta Reference 

4. Gupta describes base tables (Fig. 1A), materialized views (Fig. 
IB), as well as refresh logs and views (Figs. 4B-1, 4B-2, 4C-1, & 4C-2). 

5. Gupta describes a materialized view divided into multiple 
partitioned sections that may be separately updated. (Col. 6, 11. 35-59; Fig. 
IB, partitions 142 & 144.) Similarly, Gupta describes multiple materialized 
views that may be separately updated, as well as multiple refresh logs and 
views. (Col. 9, 11. 27 to col. 11, 1. 2; col. 15, 1. 40 to col. 16, 1. 43; Figs. 4A, 
4B-1, 4B-2, 4C-1, & 4C-2.) Gupta describes a refresh mechanism for 
updating (refreshing) the materialized view(s) based on the refresh logs, and 
describes specific steps and corresponding SQL commands for the refresh 
operations. (Col. 7, 1. 65 to col. 13, 1. 9; col. 15, 1. 40 to col. 16, 1. 43; Figs. 
3A-3D & 5A-5E.) 
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PRINCIPLES OF LAW 

Burden on Appeal 
Appellant has the burden on appeal to the Board to demonstrate error 
in the Examiner's position. See In re Kahn, 441 F.3d 977, 985-86 (Fed. Cir. 
2006) ("On appeal to the Board, an applicant can overcome a rejection by 
showing insufficient evidence of prima facie obviousness or by rebutting the 
prima facie case with evidence of secondary indicia of nonobviousness.") 
(quoting In re Roujfet, 149 F.3d 1350, 1355 (Fed. Cir. 1998)). 

Anticipation 

Anticipation is a question of fact. In re Schreiber, 128 F.3d 1473, 
1477 (Fed. Cir. 1997). Under 35 U.S.C. § 102, "[a] claim is anticipated only 
if each and every element as set forth in the claim is found, either expressly 
or inherently described, in a single prior art reference." Verdegaal Bros., 
Inc. v. Union Oil Co. ofCai, 814 F.2d 628, 631 (Fed. Cir. 1987) (citations 
omitted); see also Perricone v. Medicis Pharm. Corp., 432 F.3d 1368, 1375 
(Fed. Cir. 2005)(citation omitted). 

Obviousness 

A claimed invention is not patentable if the subject matter of the 
claimed invention would have been obvious to a person having ordinary skill 
in the art. 35 U.S.C. § 103(a); KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398, 
406 (2007); Graham v. John Deere Co., 383 U.S. 1, 13 (1966). The 
question of obviousness is resolved on the basis of underlying factual 
determinations including (1) the scope and content of the prior art, (2) any 
differences between the claimed subject matter and the prior art, (3) the level 
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of skill in the art. Graham, 383 U.S. at 17. See also KSR, 550 U.S. at 407 

("While the sequence of these questions might be reordered in any particular 

case, the [Graham] factors continue to define the inquiry that controls.") 

In KSR, the Supreme Court emphasizes "the need for caution in 

granting a patent based on the combination of elements found in the prior 

art," and stated that "[t]he combination of familiar elements according to 

known methods is likely to be obvious when it does no more than yield 

predictable results." KSR, 550 U.S. at 415-16. The Court explained: 

When a work is available in one field of endeavor, design 
incentives and other market forces can prompt variations of it, 
either in the same field or a different one. If a person of 
ordinary skill can implement a predictable variation, § 103 
likely bars its patentability. For the same reason, if a technique 
has been used to improve one device, and a person of ordinary 
skill in the art would recognize that it would improve similar 
devices in the same way, using the technique is obvious unless 
its actual application is beyond his or her skill. 

Id. at 417. The operative question is thus "whether the improvement is more 
than the predictable use of prior art elements according to their established 
functions." Id. 

ANALYSIS 

Issue I: Rejection of claims 1, 3, 5, 11-17, and 20 under 
35 U.S.C. § 102(b) 

Sun describes a system that performs a fast refresh on a database 

snapshot view. The snapshot is a viewable (materialized view) data 

construct utilizing data from a database master table. The master table data 

may also be viewed in a master view. Sun's system detects modifications to 

the master table and stores related data values (primary key values) in a 
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master log for the rows of the master table that change. Sun describes a 
"fast refresh mechanism" that includes programming operable to perform 
refresh functions on the snapshot. During the refresh of the snapshot Sun's 
system reconciles the snapshot and the master table/master view utilizing 
SQL statements that in turn utilize the primary key values associated with 
the master table and stored in the master log. (FF 1-3.) Thus, we find that 
an ordinarily- skilled artisan would have understood Sun to describe a system 
for performing refresh operations, the system including: a master table 
containing data values; a snapshot (materialized) view constructed from data 
in the master table; a master log containing primary key values associated 
with changes to the master table; and programming for refreshing (updating) 
the snapshot. 

The Examiner finds that the prior art discloses and/or teaches each 
feature of Appellants' claims (Ans. 3-12), and maintains that each of the 
claims is properly rejected (Ans. 13-17). 

Appellants, however, present a number of arguments generally 
asserting that the Sun reference does not disclose each of the claimed 
features of claim 1. We address each argument in the order presented by 
Appellants, infra. 

We note at the outset, as a general proposition, merely reciting that 
data corresponds to a particular type of data, e.g., a "first plurality of data 
entries" or a "second plurality of data entries," as opposed to some other 
unique identifier, essentially constitutes non-functional descriptive material 
as it does not further limit the claimed invention either functionally or 
structurally. Similarly, reciting that a "log," "view," or "module" 
corresponds to a particular type or function, e.g., a "delta adaptation 



10 



Appeal 2009-004053 
Application 10/813,843 

module," as opposed to some other unique identifier, does not further limit 
the claimed invention either functionally or structurally. Such non- 
functional descriptive material does not patentably distinguish claims over 
the prior art that otherwise renders the claims unpatentable. In re Ngai, 367 
F.3d 1336, 1339 (Fed. Cir. 2004). 4 

We determine the scope of the claims in patent applications not solely 
based on the claim language, but upon giving claims "their broadest 
reasonable interpretation consistent with the [Specification" and "in light of 
the [Specification as it would be interpreted by one of ordinary skill in the 
art." In re Am. Acad. ofSci. Tech Or., 367 F.3d 1359, 1364 (Fed. Cir. 2004) 
(citations omitted). 

We have carefully reviewed claim 1 and interpreted its scope in view 
of current legal guidance. (See In re Ngai, 367 F.3d at 1338.) With regard 
to the limitations actually recited in representative claim 1, the labeling of 
certain features, as discussed supra, is a non-functional distinction - 
specifically, a "base" table, a "refresh" log, "delta" values, and a "delta 
adaptation" module - as these "names" do not functionally distinguish the 
claim elements. Thus, when confronted with a reference that otherwise 
provides the claimed features - a data table, a data log containing data 
associated with data table modifications, data associated with data table 
modifications (i.e., changes, differences, or deltas), or computer 

4 See also Ex parte Nehls, 88 USPQ2d 1883, 1887-89 (BPAI 2008) 
(precedential) (discussing cases pertaining to non-functional descriptive 
material); Ex parte Mathias, 84 USPQ2d 1276 (BPAI 2005), aff'd by In re 
Mathias, 191 Fed. Appx. 959 (Fed. Cir. 2006) (Rule 36, unpublished); Ex 
parte Curry, 84 USPQ2d 1272 (BPAI 2005) (informative), aff'd by In re 
Curry, No. 2006-1003 (Fed. Cir. 2006) (Rule 36, unpublished) (both cases 
treating data as nonfunctional descriptive material). 
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programming manipulating data to perform a particular function (e.g., 
updating a view (delta adaptation)) - in the manner claimed, but chooses to 
label them differently, we cannot give significant patentable weight to such 
labels. 

a. Argument That Sun Doesn't Disclose a Module Configured To 
Access a Refresh Log and a First Materialized View 

We first address Appellants' contention that the Examiner improperly 
rejected claim 1 as anticipated by Sun because the Sun reference doesn't 
disclose a "module configured to access the refresh log and the first 
materialized view." (Br. 14.) 

The Examiner finds that Sun discloses refresh operations accessing 
the master log and the snapshot. (Ans. 4, 13.) Accordingly, we decide the 
question of whether the Sun reference discloses a module configured to 
access the refresh log and the first materialized view. 

After reviewing the record on appeal, we find the Sun reference 
discloses the disputed limitation. We interpret, broadly but reasonably (see 
Am. Acad. ofSci. Tech Ctr., 367 F.3d at 1364, supra) the terminology of the 
disputed limitation. Appellants' "refresh" log is a data construct storing 
database change data. Appellants' "first materialized" view is a viewable 
data construct including a set of data. And, Appellants' "module" is 
computer program manipulating data to perform a particular function. Thus, 
we agree with the Examiner's findings that Appellants' refresh log and first 
materialized view read on Sun's master log and snapshot. (FF 1; Ans. 3-4.) 
We also find that Sun discloses a computer program that accesses the master 
log and snapshot. (FF 1-3.) We are not persuaded by Appellants' contrary 
arguments that Sun does not disclose the disputed features, especially in 
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view of Appellants' misconstruction of the Examiner's basis for the 
rejection - that the Examiner "incorrectly equates Sun's master table for 
Appellants' claimed refresh log" (Br. 14). 

Appellants did not file a Reply Brief, nor did Appellants provide any 
persuasive evidence supporting the assertions of alleged error in the 
Examiner's position. Accordingly, Appellants have not met the burden to 
show error in the Examiner's findings. 

b. Argument That Sun Doesn't Disclose a Module Adapted To 
Perform a Refresh Operation On The First Materialized View 
Using The Second Plurality Of Data Entries 

We next address Appellants' contention that the Examiner improperly 
rejected claim 1 as anticipated by Sun because the Sun reference doesn't 
disclose "a module adapted to perform a refresh operation on the first 
materialized view using the second plurality of data entries." (Br. 15.) 

The Examiner finds that Sun discloses refresh operations on the 
snapshot. (Ans. 4, 13-14.) Accordingly, we decide the question of whether 
the Sun reference discloses a module adapted to perform a refresh operation 
on the first materialized view using the second plurality of data entries. 

After reviewing the record on appeal, we find the Sun reference 
discloses the disputed limitation. Appellants' "second plurality of data 
entries" is non-functional descriptive material (see discussion supra). 
Appellants do not explicitly define the "second plurality of data entries" in 
their Specification or in the claim. Nor, does the language of Appellants' 
claim 1 preclude the "first" and "second" data entries from being identical, 
or otherwise distinguish the data sets from one another. Therefore, we 
broadly but reasonably interpret Appellants' "second plurality of data 
entries" as merely a second data set. We agree with the Examiner's findings 
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and we also find that Sun discloses computer programming to refresh/update 
the snapshot - i.e., a first materialized view (see discussion supra). The data 
making up the snapshot - i.e., the second plurality of data entries - is merely 
a (second) set of data from the master table. Sun's refresh mechanism 
utilizes this data to refresh the snapshot. (FF 1 & 3.) We are not persuaded 
by Appellants' contrary arguments that Sun does not disclose the disputed 
features because Appellants, as pointed out by the Examiner (Ans. 14), do 
not explain how or why the Examiner's findings are in error. 

Appellants did not file a Reply Brief, nor did Appellants provide any 
persuasive evidence supporting the assertions of alleged error in the 
Examiner's position. Accordingly, Appellants have not met the burden to 
show error in the Examiner's findings. 

c. Argument That Sun Doesn't Disclose a Module For Calculating 
Delta Values From a Plurality Of Changes In A Refresh Log and a 
Second Plurality Of Data Values In a First Materialized View 

We next address Appellants' contention that the Examiner improperly 
rejected claim 1 as anticipated by Sun because the Sun reference doesn't 
disclose "calculating [a plurality of] delta values from a plurality of changes 
in a refresh log and a second plurality of data values in a first materialized 
view." (Br. 15-16.) 

The Examiner finds that Sun discloses calculating change values or 
differences from the master log and the snapshot. (Ans. 4, 14-15.) 
Accordingly, we decide the question of whether the Sun reference discloses 
calculating delta values from changes in a refresh log and a second plurality 
of data values in a first materialized view. 

After reviewing the record on appeal, we find the Sun reference 
discloses the disputed limitation. As we explained supra, Sun discloses 
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computer programming that stores database changes in a master (refresh) 
log, and that refreshes/updates the snapshot utilizing data making up the 
snapshot from the master table. Appellants, as pointed out by the Examiner, 
do not explicitly define the "delta values" in their Specification or in the 
claim, and we find (supra) that this terminology is non-functional descriptive 
material. Therefore, we broadly but reasonably interpret Appellants' "delta 
values" as merely data associated with database (data table, base table, or 
master table) modifications, changes, or differences - i.e., deltas. We agree 
with the Examiner's findings and we also find that Sun discloses 
determining or calculating change data (values) from data in the master 
(refresh) log and the snapshot. (FF 1 & 3.) 

Appellants did not file a Reply Brief, nor did Appellants provide any 
persuasive evidence supporting the assertions of alleged error in the 
Examiner' s position. Accordingly, Appellants have not met the burden to 
show error in the Examiner's findings. 

d. Argument That Sun Doesn't Disclose a Module Configured To 
Apply a Plurality Of Delta Values To a Second Plurality Of Data 
Entries In a First Materialized View 

Lastly, we address Appellants' contention that the Examiner 
improperly rejected claim 1 as anticipated by Sun because the Sun reference 
doesn't disclose "a module configured to apply a plurality of delta values to 
the second plurality of data entries in a first materialized view." (Br. 17.) 

The Examiner finds that Sun discloses applying delta values 
(differences in the database) to the snapshot. (Ans. 4, 15.) Accordingly, we 
decide the question of whether the Sun reference discloses a module 
configured to apply a plurality of delta values to a second plurality of data 
entries in a first materialized view. 
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After reviewing the record on appeal, we find the Sun reference 
discloses the disputed limitation. As we explained supra, Sun discloses 
computer programming that determines differences in database data, and 
refreshes/updates the snapshot utilizing this data and data making up the 
snapshot from the master table. Appellants do not explicitly define the term 
"apply," or explain how the "delta values" are applied to the data of the 
"first materialized view," either in their Specification or in the claim. We 
understand the term "apply" in this context to mean "to join with." 
Therefore, we broadly but reasonably interpret "a module configured to 
apply a plurality of delta values to a second plurality of data entries in a first 
materialized view" as computer programming to join the change data (data 
associated with database changes or differences) with the data of the 
materialized view. We agree with the Examiner's findings and we also find 
that Sun discloses joining change data with the data of the snapshot. (FF 1 
&3.) 

Appellants did not file a Reply Brief, nor did Appellants provide any 
persuasive evidence supporting the assertions of alleged error in the 
Examiner's position. Accordingly, Appellants have not met the burden to 
show error in the Examiner's findings. 

For all the foregoing reasons, Appellants have not persuaded us of 
error in the Examiner's anticipation rejection claims 1, 3, 5, 11-17, and 20. 
Accordingly, we affirm the Examiner's rejection of these claims. 

Issue 2: Rejection of Claims 2, 4, 6-10, 18, 19, 21, and 22 under 
35 U.S.C. § 103(a) 

Appellants also contend that the Examiner improperly rejected claim 

6 as obvious in view of the combination of the Sun and Gupta references 
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because the references collectively do not teach: (1) "a first delta calculation 
module that calculates a plurality of delta values that represents the changes 
to the first materialized view (Br. 21); (2) "a first delta processing module 
that applies the plurality of delta values to the first materialized view" (Br. 
21); and (3) "a second delta calculation module or a second processing delta 
[sic] module" (Br. 22). 

The Examiner finds that Sun and or Gupta each of these features. 
(Ans. 4, 10, 13-17.) Accordingly, we decide the question of whether the Sun 
and Gupta references collectively teach a first delta calculation module, a 
first delta processing module, a second delta calculation module, and a 
second delta processing module as claimed in claim 6. 

As with claim 1 supra, we find that Appellants' first delta calculation 
module, first delta processing module, second delta calculation module, and 
second delta processing module are non-functional descriptive material, as 
these "modules" do not distinguish over prior art references that teach 
performing the same functions. 

After reviewing the record on appeal, we find the Sun and Gupta 
references collectively teach a first delta calculation module, a first delta 
processing module, a second delta calculation module, and a second delta 
processing module as claimed in claim 6. As we explained with respect to 
claim 1 supra, Sun teaches computer programming that determines change 
values that represent modifications to the data in the snapshot - i.e., a first 
delta calculation module that calculates a plurality of delta values that 
represents the changes to the first materialized view. Also, as we explained 
with respect to claim 1 supra, Sun teaches computer programming that joins 
the change values to the data of the snapshot - i.e., a first delta processing 
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module that applies the plurality of delta values to the first materialized 
view. 

We agree with the Examiner's findings (Ans. 10) and we also find 
that Gupta teaches: (1) computer programming that calculates change values 
that represent modifications to the data in a second materialized view - i.e., 
a delta adaptation module that receives the plurality of delta values from the 
first delta calculation module and calculates a plurality of changes to the 
second materialized view and a second delta calculation module that obtains 
the plurality of changes to the second materialized view from the delta 
adaptation module; and (2) computer programming that joins (applies) the 
change values to a second materialized view - i.e., a second delta processing 
module that applies the plurality of changes to the second materialized view 
from the second delta calculation module to the second materialized view. 
(FF 4 & 5.) We note that Appellants merely state that Gupta does not 
"disclose a second delta calculation module or a second processing delta 
module as recited by independent claim 6." This is insufficient to overcome 
the Examiner's findings that Gupta teaches these features. 

Although ultimately unnecessary to the decision, we agree with the 
Examiner (Ans. 10, 15-17) that Gupta also teaches determining change 
values that represent modifications to the data in a first materialized view 
(i.e., a first delta calculation module), and joining (applying) the change 
values to the data in a first materialized view (i.e., a first delta processing 
module). (FF4&5.) 

Appellants did not file a Reply Brief, nor did Appellants provide any 
persuasive evidence supporting the assertions of alleged error in the 
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Examiner's position. Accordingly, Appellants have not met the burden to 
show error in the Examiner's findings. 

For all the foregoing reasons, Appellants have not persuaded us of 
error in the Examiner's obviousness rejection of claims 2, 4, 6-10, 18, 19, 
21, and 22. Accordingly, we affirm the Examiner's rejection of these 
claims. 

CONCLUSION OF LAW 
On the record before us, we find that Appellants have not established 
that the Examiner erred in finding the Sun reference discloses: (1) a module 
configured to access a refresh log and a first materialized view; (2) a module 
adapted refresh a first materialized view using a second plurality of data 
entries; (3) a module calculating a plurality of delta values from a plurality 
of changes in a refresh log and a second plurality of data values in a first 
materialized view; and (4) a module configured to apply a plurality of delta 
values to a second plurality of data entries in a first materialized view. We 
also find that Appellants have not established that the Examiner erred in 
finding the Sun and Gupta references collectively teach or would have 
suggested: (1) a first delta calculation module that calculates a plurality of 
delta values that represents the changes to the first materialized view; (2) a 
first delta processing module that applies the plurality of delta values to the 
first materialized view; and (3) a second delta calculation module or a 
second delta processing module. 
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DECISION 

We affirm the Examiner's rejections of claims 1-22 under 
35 U.S.C. §§ 102(b) and 103(a). 

AFFIRMED 
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